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Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 . 1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and wilt expire SIX (6) MONTHS from the mailing date of this communication. 
• Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 

Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment See 37 CFR 1.704(b). 

Status 

1 )E3 Responsive to communication(s) filed on 07 January 2004 . 
2a)l3 This action is FINAL. 2b)D This action is non-final. 

3) Q Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayie, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) E3 Claim(s) 16-21 and 27-44 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) E3 Claim(s) 16-21. 27-44 is/are rejected. 

7) Q Claim(s) is/are objected to. 

8) 0 Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10)D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
1 1 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12)Q Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)Q All b)D Some * c)Q None of: 

1 .□ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. Q Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 
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DETAILED ACTION 

1. Claims 16-21, 27-44 are pending. This action is in response to the amendment 
filed 1/7/2004. Applicant has amended claims 16, 27, 29 and 42. 

2. The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 

3. Claims 16, 18-20, 27, 28, 42, 43 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Baxter et al (U S Pat. 6,289,500) in view of Sonderegger (U S Pat. 
5,761 ,499). 

As to claims 16 and 42, Baxter teaches a system (IBM San Francisco framework) 
for extending functionality (to include domain-specific functions) of a class object 
(Extensibleltem class which is domain-neutral), comprising: processing unit (110); 
system memory (120); system bus (160); computer-readable medium (155); and an 
extensible object model (San Francisco Framework) executed from, wherein the 
extensible object model creates (DomainltemCreator) an extension object 
(DomainExtension object) from an existing extension package (DomainExtension class 
which implements domain-specific functions) when a requested functionality (domain- 
specific functions) is not inherent in the class object [it is noted that the domain-neutral 
extensible items/objects do not provide domain-specific functions], and wherein the 
extension object extends the class object to provide the requested functionality (provide 
domain-specific functions to domain-neutral extensible items/objects). See col. 8, lines 
45-61; col. 10, line 19- col. 11, line 67. 

Baxter does not explicitly teach the extensible object model determines whether 
a requested functionality is inherent in the class object. 

Sonderegger teaches extending functionality of a class object (COM object), 
including determining whether a requested functionality is inherent (registered in registry 
file 44 / OLE registry file) in the class object (check the registry file 44 for availability of 
the desired COM component, col. 8, lines 37-56; col. 9, lines 12-32; col. 10, lines 31- 
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38). If the requested functionality is not inherent in the class object (the desired COM 
component not registered in registry file 44), an extension package is located (query 
directory services and database 52 for unregistered COM/OLE components on 
component server, col. 10, line 39 - col. 11, line 10) to create an extension object (COM 
interface ICIassFactory). Given the teaching of Sonderegger, it would have been 
obvious to include a step to determine whether a requested functionality is inherent in 
the class object. A motivation to combine the teaching of Baxter with Sonderegger 
would have been to use extension packages located on other nodes of the network 
(Sonderegger, col. 11, lines 52-65) to provide more resources of extensions. 

It is noted that the extension package of Sonderegger is an existing extension 
package in that it exists on another node (such as 46) of the network. It is further noted 
that registry file 44, implemented as an OLE registry file, of Sonderegger contains 
information about each COM component/object including its functionality/services the 
component/object offers (col. 1, lines 38-57; col. 2, lines 5-24), ie, functionality inherent 
to the component/object. Only functionality/services registered in the OLE registry file 
are offered/available to the client / inherent to the component/object. The registry file 44, 
/ OLE registry file and database 52 are separate entities in Sonderegger. 

As to claim 18, 43, Baxter teaches registering the extension package in an 
extension database (persistent collection, col. 11, lines 16-22). 

As to claim 19, Baxter teaches store the extension object in system memory 
(dynamic virtual function table) when the corresponding extension is first referenced 
(col. 7, lines 20-29. 

As to claim 20, Baxter teaches creating an extension provider object (factory 
ExtensibleltemSpecialFactory) and create the extension object from the extension 
provider object (create extensions). See col. 11, lines 1-67. 

As to claim 27, Baxter teaches extensible object (Extensibleltem), extension 
database (persistent collection) having an entry for an extension (extension for a 
particular domain, ie, of type Domainlnterface) for the extensible object; existing 
extension package (DomainExtension class and DomainltemCreator) having an 
interface for obtaining (DomainltemCreator) an extension object (DomainExtension) that 
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provides the extension for the extensible object. See col. 10, line 19 - col. 11, line 67. 
Note discussion of claim 16 for the determining step and a motivation to combine the 
teachings of Baxter / Graser / IBM San Francisco framework with Sonderegger. 

As to claim 28, Baxter teaches a call to the interface in the extension package 
(client call). See col. 10, lines 64-67. 

4. Claim 34 is rejected under 35 U.S.C. 103(a) as being unpatentable over Graser 
et al (U S Pat. 6,275,979) in view of Sonderegger (U S Pat. 5,761 ,499). 

As to claim 34, Graser teaches a method (San Francisco framework) for 
extending functionality (support additional method) of a class object (Extensibleltem) in 
a run-time environment (at run-time), comprising: receiving a request (invokeMethod()) 
from an application (client) for functionality that is not inherent in the class object [it is 
noted that Extensibleltem has no domain-specific information]; determining if the 
functionality is available (locate the method name via method table) in a first extension 
object (Extensionl); and directing the request to the functionality in a second extension 
object (Extension2), when the functionality is not available in the first extension object [It 
is noted that when looking for arb() method, Extension2 will be returned instead of 
Extensionl]. See col. 5, line 58 - col. 6, line 8; col. 6, line 30 - col. 7, line 18; col. 9, lines 
2-9; col. 11, lines 6-10. Note discussion of claim 16 for the determining step and a 
motivation to combine the teachings of Graser / IBM San Francisco framework with 
Sonderegger. 

5. Claims 17, 29-33, 35-41, 44 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over the IBM San Francisco framework as disclosed by Baxter et al and 
Graser et al in view of Sonderegger. 

It is noted that both Baxter and Graser describe the run-time operations of the 
same IBM San Francisco framework, emphasizing on different aspects. The 
combination of Baxter and Graser provides a more complete picture of the San 
Francisco framework. Therefore, it would have been obvious to combine the teachings 
to provide enhancement in various aspects. 
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As to claim 17, IBM San Francisco framework provides (Graser) notifying the 
extensible object when the extension object is deleted (previous extension overridden 
and deleted, col. 7, lines 18-53). 

As to claim 29, the IBM San Francisco framework provides (Baxter) a method for 
extending functionality (new domain extension) of a class object (Extensibleltem) in a 
run-time environment (San Francisco framework), comprising: receiving a request from 
an application (client invokes) for functionality that is not inherent in the class object 
(new domain extension needed); determining if the functionality is available in a first 
extension object (locate special factory ExtensibleltemSpecialFactory); obtaining an 
extension package (classes, collections and factories) having computer-executable 
instructions associated with the extension object functionality (extension of type 
Domainlnterface), wherein the extension package proffers an extension provider object 
(special factory) when the functionality is requested; specifying parameters (pass 
domain parameters) to the extension provider object to create a second extension 
object (create extension object via ExtensibleltemFactory). See coL 11, lines 6-67. The 
IBM San Francisco framework also provides (Graser) a step for directing the invocation 
to the second extension object (Extension2 which implements the requested arb()) after 
the second extension object has been created. See col. 5, line 58 - col. 6, line 8; col. 6, 
line 30 - col. 7, line 18; col. 9, lines 2-9; col. 11, lines 6-10. Note discussion of claim 16 
for the determining step and a motivation to combine the teachings of Baxter / Graser / 
IBM San Francisco framework with Sonderegger. 

As to claim 30, note discussion of claim 18. 

As to claims 31, 36, note discussion of claim 27 (Baxter) for storing the extension 
package in an extension database. 

As to claims 32, 40, San Francisco framework provides (Graser) searching for an 
entry associated with the functionality (col. 6, lines 9-41). 

As to claims 33, 41, San Francisco framework provides (Graser) creating the 
second extension object when the extended functionality is first referenced (create new 
extension and add to method table), and locating (look up method name) the second 
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extension object when the extended functionality is subsequently referenced (col. 6, 
lines 9-65). 

As to claim 35, note discussion of claim 29 for obtaining an extension package. 
As to claim 37, note discussion of claim 18. register the extension package in an 
extension database stored on. 

As to claims 38 and 39, note discussion of claim 20. 

As to claim 44, the IBM San Francisco framework provides (Baxter) a method for 
extending functionality (new domain extension) of a class object (Extensibleltem which 
is domain-neutral), comprising: invoking (client invokes) a functionality that is not 
inherent in the class object (new domain extension); determining if the invoked 
functionality is available in a first extension object (look for special factory 
ExtensibleltemSpecialFactory that should be used); creating a second extension object 
(use standard factory ExtensibleltemFactory) when the invoked functionality is not 
available in the first extension object (otherwise use the standard factory). See col. 1 1 , 
lines 1-11, 39- 50. The IBM San Francisco framework also provides (Graser) a step for 
directing the invocation to the second extension object (Extension2 which implements 
the requested arb()) after the second extension object has been created. See col. 5, line 
58 - col. 6, line 8; col. 6, line 30 - col. 7, line 18; col. 9, lines 2-9; col. 11, lines 6-10. Note 
discussion of claim 16 for the determining step and a motivation to combine the 
teachings of Baxter / Graser / IBM San Francisco framework with Sonderegger. 

6. Claim 21 is rejected under 35 U.S.C. 103(a) as being unpatentable over Baxter 
et al in view of Sonderegger as applied to claim 16 and further in view of Schmidt et al 
("An Object-Oriented Framework for Developing Network Server Daemons"). 

As to claim 21, Schmidt teaches framework based software architecture (service 
configuration), including creating an event filtering and sourcing object (event handler) 
to handle events (events) generated by an extension object (service object). See pages 
7-8, section 4.1. Therefore, it would have been obvious to create an event filtering and 
sourcing object in Baxter to handle events generated by an extension object. In so 
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doing, configuring different types of I/O events from a client would have been simplified 
with the class library (page 6, section 3.2.3). 

7. Applicant's arguments filed 1/7/2004 have been fully considered but they are not 
persuasive. 

Regarding applicant's argument that Sonderegger^ teaching of determining 
whether a functionality is registered in the registry does not teach the present 
invention's determination of whether functionality is inherent to a class object because 
the two concept are distinct which is reflected in dependent claims 18, 30 and 37 and in 
the specification, page 12, lines 12-14. (Remarks, page 7-8). 

The examiner's response is as follows. First, any functionality inherent to an 
object is the functionality which is offered by the object and is available for invocation, 
as one of ordinary skill in the art would recognize. Sonderegger teaches COM/OLE 
components/objects which offer functionality/services. Sonderegger further teaches 
registry file 44, implemented as an OLE registry file and separate from the component 
database 52, contains information about each component/object including the 
functionality/services each component/object offers. See Sonderegger, col. 1, lines 38- 
57; col. 2, lines 5-24. Functionality/services registered in the registry file 44 are offered 
and available for invocation. In other words, in Sonderegger the functionality/services 
registered in the registry file 44 are the functionality inherent to the component/object. 

Second, Sonderegger determines whether a requested functionality is inherent to 
an object by checking whether it is offered/available which in tern by checking whether it 
is registered in registry file 44, the OLE registry file. See col. 8, lines 37-56; col. 9, lines 
12-32; col. 10, lines 31-38. In Sonderegger if the requested functionality is not inherent 
to the object (the desired COM component not registered in registry file 44), an existing 
extension package is located (query directory services and database 52 to locate 
COM/OLE components resident on component server but not registered in file 44, col. 
10, line 39 -col. 11, line 10). 

Third, contrary to applicant's characterization, dependent claims 18, 30 and 37 
do not recite If the method or property is not inherent to the object being referenced, 
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the runtime environment determines if the extension is registered in the extension 
database". Claims 18, 30 and 37 simply recite registering the extension package with 
the extension database, which does not include the argued pre-condition/distinction "if 
the method or property is not inherent to the object being referenced". 

Fourth, the disclosed "if the method or property is not inherent to the object being 
referenced, the runtime environment determines if the extension is registered in the 
extension database" (specification, page 12, lines 12-14) is not claimed. During 
examination, claim limitations are interpreted in light of the specification, but the 
specification is not read into the claims. The extension database as claimed is met by 
the persistent collection of Baxter and is analogous to the component database 52 of 
Sonderegger. 

Regarding the amended existing extension package (Remarks, page 8, 2 nd 
para.), this is met by the DomainExtension class of Baxter which implements domain- 
specific functions, which exists (vs. newly created) in Baxter. Sonderegger also teaches 
COM/OLE components reside/exist on and registered with the component server but 
not registered with registry file 44. Note discussion of claim 16 for detail. 

8. THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for response to this final action is set to expire 
THREE MONTHS from the date of this action. In the event a first response is filed 
within TWO MONTHS of the mailing date of this final action and the advisory action is 
not mailed until after the end of the THREE-MONTH shortened statutory period, then 
the shortened statutory period will expire on the date the advisory action is mailed, and 
any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date 
of the advisory action. In no event will the statutory period for response expire later 
than SIX MONTHS from the date of this final action. 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sue Lao whose telephone number is (703) 305-9657. A 
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voice mail service is also available at this number. The fax phone numbers for the 
organization where this application or proceeding is assigned are (703) 746-7238 for 
After Final communications, (703) 746-7239 for Official communications and (703) 746- 
7240 for Non-Offlcial/Draft communications. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the Group receptionist whose telephone number is 
(703) 305-9600. 



Sue Lao <^J^n 0 
March 18, 2004 



